Mestre ytelsen til CSS View Transition-klasser: Et dypdykk i animasjonsbehandling

Den moderne nettsiden trives på sømløse brukeropplevelser, og dynamiske visuelle overganger er en hjørnestein i den forventningen. Fra subtile overtoninger til forseggjorte omorganiseringer av elementer, forbedrer jevne endringer i brukergrensesnittet (UI) engasjementet og får applikasjoner til å føles mer responsive. CSS View Transitions, et banebrytende tillegg til webplattformen, lover å demokratisere disse komplekse overgangene, og lar utviklere lage imponerende, deklarative animasjoner med relativ letthet.

Men kraften i View Transitions, spesielt når den kombineres med egendefinerte animasjonsklasser, medfører ytelseshensyn. For et globalt publikum som bruker nettet på ulike enheter og nettverksforhold, er det ikke bare fordelaktig å forstå hvordan disse animasjonsklassene behandles av nettleseren; det er kritisk. Denne omfattende guiden vil ta deg med på et dypdykk i ytelsesaspektene ved CSS View Transitions, med et spesifikt fokus på de intrikate mekanismene for behandling av animasjonsklasser, og tilbyr innsikt og beste praksis for å sikre at overgangene dine ikke bare er vakre, men også yter godt og er tilgjengelige over hele verden.

Forstå grunnlaget: Hva er CSS View Transitions?

Før vi dissikerer ytelsen, la oss kort oppsummere hva CSS View Transitions tilbyr. Tradisjonelt krevde animering av endringer mellom ulike Document Object Model (DOM)-tilstander (f.eks. navigering mellom sider, skjuling/visning av elementer, eller oppdatering av innhold) kompleks JavaScript, som ofte involverte håndtering av flere elementer, beregning av posisjoner og orkestrering av animasjoner på tvers av forskjellige komponenter. Dette kunne føre til glimt av ustilet innhold, layout-skifter og en betydelig byrde på vedlikehold for utviklere.

CSS View Transitions forenkler dette ved å tilby en deklarativ måte å animere disse DOM-endringene på. Kjerneideen er at nettleseren tar et øyeblikksbilde av den gamle DOM-tilstanden, utfører den faktiske DOM-oppdateringen, tar et øyeblikksbilde av den nye DOM-tilstanden, og deretter animerer mellom disse to øyeblikksbildene. Denne prosessen skjer i stor grad utenfor hovedtråden der det er mulig, noe som minimerer hakking (jank) og gir en jevnere brukeropplevelse.

Kjernemekanismen: Hvordan View Transitions fungerer

Magien begynner med metoden document.startViewTransition(). Når den kalles, vil nettleseren:

1. Tar et skjermbilde av den nåværende sidetilstanden.
2. Utfører DOM-oppdateringsfunksjonen du oppgir (f.eks. endring av innhold, navigering til en ny URL, veksling av CSS-klasser).
3. Tar et nytt skjermbilde av den nye sidetilstanden.
4. Oppretter et pseudo-element-tre (::view-transition) som inneholder de gamle og nye øyeblikksbildene og animerer mellom dem.

Nøkkelen til å tilpasse disse animasjonene er CSS-egenskapen view-transition-name. Ved å tildele et unikt view-transition-name til et element i både dets gamle og nye tilstand, instruerer du nettleseren til å behandle det elementet som en kontinuerlig enhet gjennom overgangen. Dette muliggjør flytende, elementspesifikke animasjoner, som for eksempel at et produktbilde jevnt vokser fra en listevisning til en detaljside.

Rollen til animasjonsklasser i View Transitions

Selv om View Transitions gir fornuftige standardanimasjoner (som kryss-toning), ligger deres sanne kraft i tilpasning. Det er her CSS-animasjonsklasser kommer inn i bildet. Ved å bruke spesifikke klasser på elementer i overgangen, kan utviklere definere sofistikerte, egendefinerte animasjoner ved hjelp av standard CSS @keyframes-regler.

Tenk deg et scenario der du vil at et spesifikt element skal gli inn fra venstre under en overgang, i stedet for bare å tone inn. Du kan definere en slide-in-left-klasse med en tilhørende @keyframes-regel. Under visningsovergangen vil du sørge for at denne klassen blir brukt på det relevante elementet i den 'nye' tilstanden, eller på selve pseudo-elementene for visningsovergangen.

Anvende klasser på View Transition pseudo-elementer

View Transitions eksponerer flere pseudo-elementer som representerer de forskjellige delene av overgangen. Disse er de primære målene for animasjonsklasser:

• ::view-transition: Rot-pseudo-elementet, som dekker hele visningsområdet.
• ::view-transition-group(name): Representerer en gruppe elementer med et spesifikt view-transition-name.
• ::view-transition-image-pair(name): Inneholder de 'gamle' og 'nye' øyeblikksbildene for et navngitt element.
• ::view-transition-old(name): Øyeblikksbildet av elementet før DOM-oppdateringen.
• ::view-transition-new(name): Øyeblikksbildet av elementet etter DOM-oppdateringen.

Ved å målrette disse pseudo-elementene med klasser, kan utviklere presist kontrollere animasjonen. For eksempel:

            .my-transition::view-transition-old(hero) {
    animation: fade-out 0.3s ease-out forwards;
}

.my-transition::view-transition-new(hero) {
    animation: slide-in 0.3s ease-in forwards;
}

            

              
                Copy
              
            
          

I dette eksempelet er .my-transition en klasse som brukes på html- eller body-elementet under overgangen for å aktivere disse spesifikke animasjonsreglene. Nettleseren behandler disse klassene og deres tilknyttede @keyframes for å utføre den ønskede visuelle effekten.

Ytelsesimplikasjoner av animasjonsklasser

Hver animasjon, spesielt de som drives av CSS-klasser, involverer nettleserens rendringsmotor. Å forstå hvordan nettleseren behandler disse animasjonene er avgjørende for å optimalisere ytelsen. Rendringspipelinen involverer vanligvis flere stadier: Stil, Layout, Paint og Composite. Ulike CSS-egenskaper påvirker ulike stadier, og ytelseskostnaden varierer betydelig.

Nettleserens rendringspipeline og animasjonsklasser

1. Stil: Nettleseren beregner de endelige stilene for alle synlige elementer. Når en animasjonsklasse legges til eller fjernes, eller når en animasjon starter/stopper, må nettleseren re-evaluere stilene.
2. Layout (Reflow): Hvis en CSS-egenskap påvirker et elements geometri (f.eks. width, height, left, top, padding, margin), må nettleseren beregne størrelsen og posisjonen til det elementet og potensielt alle dets barn og søsken på nytt. Dette er ofte det mest kostbare stadiet.
3. Paint (Repaint): Hvis en CSS-egenskap påvirker et elements visuelle utseende, men ikke dets geometri (f.eks. color, background-color, box-shadow), maler nettleseren pikslene for det elementet på nytt. Dette er mindre kostbart enn layout, men kan fortsatt være dyrt for komplekse elementer eller store områder.
4. Composite: Nettleseren tegner elementer på skjermen, ofte ved hjelp av maskinvareakselerasjon. Egenskaper som transform og opacity er ideelle for animasjon fordi de vanligvis bare utløser dette stadiet, noe som gjør dem svært ytelseseffektive.

Når du bruker en animasjonsklasse på et pseudo-element for en visningsovergang eller et vanlig DOM-element under en overgang, behandler nettleseren dens tilknyttede @keyframes. Egenskapene definert i disse @keyframes dikterer hvilke stadier av rendringspipelinen som påvirkes, og følgelig ytelseskostnaden.

Høykostnads- vs. lavkostnads-animasjonsegenskaper

• Høy kostnad: Animering av egenskaper som utløser Layout (f.eks. width, height, padding, margin, border, top, left) eller omfattende Paint (f.eks. box-shadow med komplekse uskarphetsverdier, filter på store områder) vil påvirke ytelsen betydelig. Dette er fordi disse endringene ofte tvinger nettleseren til å beregne og tegne store deler av siden på nytt.
• Lav kostnad: Animering av egenskaper som kan håndteres av kompositoren er ideelt. Disse inkluderer transform (for posisjon, skala, rotasjon) og opacity. Nettlesere kan ofte overføre disse animasjonene til GPU-en, noe som gjør dem utrolig jevne, selv på mindre kraftige enheter.

Når man definerer animasjonsklasser for View Transitions, er en vanlig fallgruve å bruke egenskaper som utløser kostbare layout- eller paint-operasjoner. Selv om View Transitions abstraherer bort noen kompleksiteter, gjelder de underliggende ytelsesprinsippene for CSS-animasjoner fortsatt. Å animere et pseudo-elements width fra 0 til 100 % kan fortsatt forårsake en reflow, selv innenfor den optimaliserte View Transition-konteksten, hvis det ikke håndteres forsiktig (f.eks. ved å sikre at det animerte elementet er isolert eller forfremmet til sitt eget komposittlag).

Dypdykk i behandling av animasjonsklasser i View Transitions

La oss pakke ut de spesifikke utfordringene og hensynene når animasjonsklasser behandles innenfor livssyklusen til View Transition.

1. Innledende stil-rekalkulering

Når document.startViewTransition() kalles, og DOM-oppdateringsfunksjonen din utføres, vil eventuelle endringer i elementklasser eller inline-stiler utløse en rekalkulering av stiler. Dette er et fundamentalt skritt. Hvis animasjonsklassene dine brukes under denne DOM-oppdateringen, vil deres grunnleggende stiler være en del av denne første rekalkuleringen. Denne fasen er generelt rask, men kan bli en flaskehals med overdrevent komplekse CSS-velgere, et veldig dypt DOM-tre, eller et stort antall stilendringer.

2. Opprettelse av pseudo-element og stil-anvendelse

Etter DOM-oppdateringen og de første øyeblikksbildene, konstruerer nettleseren ::view-transition pseudo-element-treet. Den bruker deretter eventuelle spesifikke CSS-regler som er rettet mot disse pseudo-elementene, inkludert de som er definert via animasjonsklasser. For eksempel, hvis du har en klasse .slide-in som definerer en transform-animasjon, og du bruker den på ::view-transition-new(my-element), må nettleseren parse denne regelen og forberede animasjonen.

3. Animasjonsstart og rammeproduksjon

Når pseudo-elementene er stilet og animasjonene er definert, begynner nettleseren å utføre @keyframes-reglene knyttet til animasjonsklassene dine. For hver ramme av animasjonen:

• Stiloppdatering: Nettleseren beregner de interpolerte verdiene for de animerte egenskapene (f.eks. transform-verdien ved 10 % av animasjonen).
• Layout/Paint (hvis aktuelt): Hvis de animerte egenskapene påvirker layout или paint, utløses disse stadiene. Det er her ytelsesproblemer ofte oppstår. For eksempel kan animering av width eller height forårsake gjentatte layout-rekalkuleringer på hver ramme, noe som fører til hakking.
• Composite: De oppdaterte elementene blir komponert på skjermen. Ideelt sett bør animasjoner primært treffe dette stadiet.

Nøkkelutfordringen er å holde denne prosessen så effektiv som mulig, spesielt på enheter med begrensede CPU/GPU-ressurser, som er vanlige i mange deler av verden. En kompleks animasjonsklasse som ofte utløser layout eller paint vil føre til tapte rammer, noe som resulterer i en hakkete, uprofesjonell opplevelse.

4. Rollen til view-transition-name og lagdeling

Når du bruker view-transition-name, forfremmer nettleseren ofte det navngitte elementet til sitt eget komposittlag. Dette er en ytelsesoptimalisering: elementer på sine egne lag kan flyttes, skaleres eller tones ut uten å påvirke andre deler av siden, så lenge bare transform og opacity animeres. Dette lar nettleseren overføre disse operasjonene til GPU-en, noe som forbedrer ytelsen betydelig.

Imidlertid kan det å forfremme for mange elementer til sine egne lag også ha en kostnad, da det forbruker GPU-minne. Selv om nettlesere er smarte om dette, er det noe å være klar over. Hovedfordelen med view-transition-name er at det gjør det lettere å animere et element ved hjelp av effektive, kun-kompositor-egenskaper på tvers av en DOM-endring.

Vanlige ytelsesflaskehalser med animasjonsklasser i View Transitions

1. Animering av Layout/Paint-egenskaper: Som diskutert, kan bruk av egenskaper som width, height, margin, top, left, eller komplekse box-shadows og filters i animasjonsklasser tvinge nettleseren inn i dyre layout- og paint-sykluser på hver ramme.
2. Overdrevent komplekse keyframes: Animasjoner med mange keyframes, komplekse easing-funksjoner, eller et stort antall animerte egenskaper kan øke nettleserens arbeidsmengde for stilberegning og interpolering.
3. Store eller mange animerte elementer: Å animere mange elementer samtidig, spesielt store, kan belaste ytelsen, selv om bare kun-kompositor-egenskaper brukes. Hvert animerte element krever ressurser.
4. Ineffektive CSS-velgere: Hvis animasjonsklassene dine er en del av komplekse CSS-velgere, kan nettleseren bruke mer tid på å bestemme hvilke stiler som gjelder, noe som potensielt kan påvirke den innledende stil-rekalkuleringsfasen.
5. Synkrone JavaScript layout-lesinger: Selv om View Transitions har som mål å redusere dette, kan det å lese layout-egenskaper (f.eks. element.offsetWidth) umiddelbart etter å ha gjort layout-endrende skrivinger i DOM-oppdateringsfunksjonen (inne i document.startViewTransition()) tvinge frem synkrone reflows, og dermed nulle ut noen av ytelsesfordelene.

Beste praksis for optimalisering av ytelsen til animasjonsklasser

For å oppnå jevne View Transitions, spesielt med egendefinerte animasjonsklasser, kreves en bevisst tilnærming til CSS og nettleser-rendring. Her er handlingsrettede strategier for global webutvikling:

1. Prioriter maskinvareakselererte egenskaper

Dette er den gylne regelen for webanimasjoner. Foretrekk alltid å animere transform (for posisjon, skala, rotasjon) og opacity. Disse egenskapene kan i stor grad overføres til GPU-en, og omgår layout- og paint-stadiene i rendringspipelinen. For eksempel, i stedet for å animere left og top for å flytte et element, bruk transform: translateX() translateY().

            /* Mindre ytelseseffektiv */
@keyframes slide-unoptimized {
    from { top: 0; left: 0; }
    to { top: 100px; left: 100px; }
}

/* Mer ytelseseffektiv */
@keyframes slide-optimized {
    from { transform: translate(0, 0); }
    to { transform: translate(100px, 100px); }
}

.my-element-animation {
    animation: slide-optimized 0.5s ease-out forwards;
}

            

              
                Copy
              
            
          

2. Begrens omfanget av animasjoner

Animer kun det som er absolutt nødvendig. Unngå å animere egenskaper på store, komplekse foreldre-containere hvis bare et lite barne-element trenger å endres. Jo mindre området nettleseren trenger å oppdatere, desto bedre ytelse. Bruk view-transition-name med omhu for å isolere elementer for animasjon.

3. Bruk will-change (med omhu)

CSS-egenskapen will-change er et hint til nettleseren om at en egenskap ved et element vil endre seg. Dette lar nettleseren gjøre optimaliseringer på forhånd, som å forfremme elementet til sitt eget lag. Bruk imidlertid will-change sparsomt og fjern det når animasjonen er fullført. Overforbruk kan føre til økt minneforbruk og potensielt forverre ytelsen hvis nettleserens optimaliseringer ikke er nødvendige eller blir feil anvendt.

            .my-element-animation {
    will-change: transform, opacity; /* Hint for nettleseroptimaliseringer */
    animation: slide-optimized 0.5s ease-out forwards;
}

            

              
                Copy
              
            
          

4. Forenkle keyframes og easing-funksjoner

Unngå overdrevent komplekse keyframes med mange mellomtrinn eller svært tilpassede cubic-bezier easing-funksjoner hvis enklere alternativer oppnår en lignende visuell effekt. Selv om moderne nettlesere er høyt optimaliserte, krever enklere animasjoner mindre beregning per ramme.

5. CSS Containment for isolerte oppdateringer

CSS-egenskapen contain kan være en kraftig optimalisering for isolerte komponenter. Egenskaper som contain: layout eller contain: paint forteller nettleseren at den interne layouten eller malingen av et element ikke påvirker, og ikke påvirkes av, elementer utenfor dets avgrensningsboks. Dette kan redusere omfanget av rekalkuleringer under animasjoner i slike komponenter betydelig.

            .isolated-component {
    contain: layout paint; /* Optimaliserer rendring for denne komponenten */
}

            

              
                Copy
              
            
          

6. Debounce og throttle animasjonsutløsere

Hvis dine View Transitions utløses av hyppige brukerinteraksjoner (f.eks. rask hovering, endring av størrelse), bør du debounce eller throttle hendelseslytterne for å forhindre at et overdrevent antall overganger starter i rask rekkefølge. Dette sikrer at nettleseren ikke konstant re-initialiserer og kjører overganger, noe som fører til en jevnere helhetsopplevelse.

7. Tilgjengelighet: Respekter prefers-reduced-motion

Avgjørende for global tilgjengelighet, spesielt for brukere med vestibulære lidelser. Respekter alltid medie-spørringen prefers-reduced-motion. Gi en enklere, mindre animert opplevelse for disse brukerne. View Transitions integreres godt med dette, da du kan betinget anvende animasjonsklasser basert på denne preferansen.

            @media (prefers-reduced-motion) {
    .my-transition::view-transition-old(hero),
    .my-transition::view-transition-new(hero) {
        animation: none !important; /* Deaktiver komplekse animasjoner */
    }
}

            

              
                Copy
              
            
          

8. Profilering og feilsøking med nettleserens utviklerverktøy

Den mest effektive måten å identifisere ytelsesflaskehalser på er ved å bruke nettleserens utviklerverktøy. Verktøy som Chrome DevTools (Performance-fanen, Rendering-fanen, Animation-fanen) er uvurderlige:

• Performance-fanen: Ta opp en profil under en overgang. Se etter lange rammer, store topper i layout eller paint, og evaluer bildefrekvensen. Identifiser hvilke elementer som forårsaker reflows/repaints.
• Layers-fanen: Se hvilke elementer som er blitt forfremmet til sine egne komposittlag. Dette hjelper med å forstå om view-transition-name eller will-change har ønsket effekt.
• Rendering-fanen: Aktiver “Paint Flashing” og “Layout Shift Regions” for å visuelt identifisere områder på siden som blir malt på nytt eller gjennomgår reflow under animasjonen.
• Animation-fanen: Inspiser og spill av CSS-animasjoner på nytt, juster hastighet og tidsfunksjoner for å finjustere.

Denne praktiske tilnærmingen lar utviklere finne nøyaktig hvor animasjonsklasser forårsaker ytelsesproblemer og anvende målrettede optimaliseringer.

Praktiske eksempler og globale bruksområder

La oss se på hvordan optimaliserte View Transitions med animasjonsklasser kan forbedre brukeropplevelsen på tvers av ulike globale applikasjonstyper:

1. Overgang i e-handelens produktgalleri

Tenk deg en internasjonal e-handelsside der brukere blar gjennom produktlister. Når man klikker på et produktbilde, bør det være en jevn overgang til produktdetaljsiden. I stedet for et hardt kutt eller en enkel toning, kan en View Transition få produktbildet til å se ut som det 'utvider' seg til sin større detaljvisning, mens andre elementer glir inn. Dette kan oppnås ved å gi produktbildet et view-transition-name og anvende animasjonsklasser for å kontrollere glidningen av tekst eller andre UI-elementer.

Optimaliseringsfokus: Sørg for at bildeovergangen bruker transform: scale(), og at all glidende tekst bruker transform: translateX()/Y(). Unngå å animere width/height på bildet direkte hvis mulig, eller sørg for at det håndteres av nettleserens øyeblikksbilde- og skaleringsteknologi.

2. Omorganisering av dashbord-widgets

For et globalt business intelligence-dashbord kan brukere dra og slippe widgets for å omorganisere dem eller utvide/kollapse seksjoner. View Transitions kan animere disse omorganiseringene sømløst. Når en bruker drar en widget, holder dens view-transition-name den visuelt vedvarende, mens andre widgets subtilt kan gli inn i sine nye posisjoner ved hjelp av animasjonsklasser som bruker transform for bevegelse.

Optimaliseringsfokus: Prioriter transform for all bevegelse. Hvis widgets har kompleks intern rendring, vurder contain: layout på dem for å forhindre at deres interne endringer utløser bredere reflows.

3. Flerstegsskjemaer eller introduksjonsprosesser

Mange applikasjoner, fra banktjenester til sosiale medieplattformer, bruker flerstegsskjemaer eller introduksjonsprosesser. En View Transition kan få overgangen mellom trinnene til å føles flytende og sammenhengende, i stedet for brå. For eksempel kan et inndatafelt elegant gli ut mens et nytt glir inn. Dette er perfekt for globale brukere som kanskje er nye for en applikasjons spesifikke UI/UX-mønstre.

Optimaliseringsfokus: Hold de animerte elementene minimale. Bruk transform for glideeffekter. Hvis innholdet i hvert trinn er veldig forskjellig, sørg for at DOM-oppdateringen er effektiv.

4. Responsive navigasjonsmenyer

På mobile enheter glir navigasjonsmenyer ofte inn fra siden. View Transitions kan forbedre dette, spesielt hvis menyinnholdet endres litt eller hvis sideinnholdet under trenger en subtil forskyvning. Å bruke animasjonsklasser på meny-containeren og potensielt hovedinnholdsområdet for en translateX-effekt kan skape en polert opplevelse.

Optimaliseringsfokus: Hele menyens glidning bør bruke transform: translateX(). Hvis sideinnholdet 'skyves' eller 'legges over', sørg for at den effekten også er optimalisert for transform- eller opacity-endringer, og utnytter lagdelingsmulighetene i View Transitions.

Verktøy og teknikker for dypere analyse

Utover nettleserens innebygde utviklerverktøy, kan flere eksterne verktøy og teknikker ytterligere hjelpe med ytelsesanalyse:

• Lighthouse Audits: Integrer Lighthouse i utviklingsarbeidsflyten din. Det gir automatiserte revisjoner av ytelse, tilgjengelighet, SEO og beste praksis. Selv om det ikke er direkte fokusert på View Transitions, vil det fange opp generelle ytelsesproblemer med animasjoner.
• Web Vitals: Overvåk Core Web Vitals (LCP, FID, CLS) i felt. Jevne animasjoner bidrar til bedre brukeropplevelsesmetrikker, og reduserer Cumulative Layout Shift (CLS) hvis de håndteres godt.
• Egendefinert ytelsesovervåking: For veldig spesifikke scenarier kan du bruke JavaScripts requestAnimationFrame for å spore faktiske bildefrekvenser under en animasjon. Dette gir granulær kontroll og kan hjelpe med å identifisere mikro-hakking som kanskje ikke er åpenbart i bredere profileringsverktøy.
• Headless Browser Testing: Bruk verktøy som Puppeteer eller Playwright for å automatisere ytelsestester. Du kan skripte navigasjon og overganger, og deretter fange opp ytelsesmetrikker for å sikre jevn ytelse på tvers av builds og miljøer.

Fremtiden for View Transitions og ytelse

CSS View Transitions er fortsatt under utvikling. Nettleserleverandører jobber kontinuerlig med å optimalisere de underliggende mekanismene, forbedre effektiviteten og utvide deres evner. Etter hvert som spesifikasjonen modnes, kan vi forvente:

• Enda mer effektivt øyeblikksbilde- og rendringsteknologi.
• Potensielt nye CSS-egenskaper eller pseudo-elementer som gir finere kontroll over overgangsadferd og ytelseshint.
• Bedre integrasjon med andre web-API-er og rammeverk, noe som gjør det enklere å implementere komplekse overgangsmønstre.

Utviklermiljøets tilbakemeldinger og reell bruk vil spille en avgjørende rolle i å forme disse fremtidige utviklingene. Ved å forstå de nåværende ytelseskarakteristikkene og anvende beste praksis, kan utviklere bidra til en mer ytelsessterk og visuelt rik web for alle.

Konklusjon: Skape ytelsessterke og engasjerende globale brukeropplevelser

CSS View Transitions representerer et betydelig sprang fremover for webanimasjon, og forenkler det som en gang var en kompleks bestrebelse. Deres sanne potensial låses imidlertid bare opp når utviklere nærmer seg dem med en skarp forståelse for ytelse. Behandlingen av animasjonsklasser krever spesielt nøye vurdering av nettleserens rendringspipeline, favorisering av maskinvareakselererte egenskaper, fornuftig bruk av view-transition-name, og grundig profilering med utviklerverktøy.

For et globalt publikum er ytelse ikke en luksus; det er en nødvendighet. En treg eller hakkete animasjon kan være en frustrerende barriere, spesielt for brukere på mindre kraftige enheter eller med begrenset nettverksbåndbredde. Ved å følge optimaliseringsstrategiene som er skissert i denne guiden, kan utviklere skape View Transitions som ikke bare er visuelt engasjerende, men også svært ytelsessterke, tilgjengelige og inkluderende, og leverer en konsekvent jevn og profesjonell opplevelse i alle verdenshjørner.

Omfavn kraften i View Transitions, men prioriter alltid ytelse. Brukerne dine, uansett hvor de er, vil takke deg for det.